It is useful for companies to know exactly what assets they have for many different reasons, but it is difficult to know this for large companies and governmental entities. Manually collecting such data on a periodic basis is expensive and time consuming. Systems have been developed by companies such as BDNA of Mountain View, Calif. to take automated inventory of assets. IBM Tivoli is another such system.
Sometimes, customers have IBM or BMC CMDB structured databases (the IBM Tivoli Change and Configuration Management Database or CMDB) of their assets and the attributes thereof but the customer likes the way automated inventory collection of attribute data about a company's assets is collected by another system such as the BDNA automated inventory software provided by BDNA in Mountain View, Calif. The BDNA software stores the attribute data in a different format and with different semantics than other systems like IBM CMDB. Sometimes in such situations, the customer may wish to continue to use the IBM CMDB data model but use BDNA software to collect the attribute data about the customer's assets. In such cases, it is useful to be able to extract automatically collected asset attribute data from BDNA data repositories and be able to make that data available on other data repositories such as those provided in asset management systems or inventory systems developed by IBM and BMC. A system to map from one data model to another and make all changes in semantics, data types, class structure, inheritance relationships, etc. is needed to do this.
The IBM Tivoli CMDB has configuration and tracking functionality that does automated, agentless discovery of the assets in use by an entity and their configuration and application dependencies. The items discovered are called Configuration Items or CIs for short. Wikipedia defines a Configuration Item as “a collection of objects related to the specific functionality of a larget system.” Discovery information about a system is one aspect of a CI, but there is usually other information about each CI maintained in its CMDB. For example, Number of trouble tickets an administrator has logged against a computer system; original set of applications installed on it; and, how they were configured. Discovery data is used to reconcile/enforce known data about a CI against item. For example, the discovery data may include: Current list of applications found in the system; or, up times collected about the system.
Another source defines a Configuration Item as:                “ . . . any component of an information technology infrastructure that is under the control of configuration management. Configuration Items (CIs) can be individually managed and versioned [sic], and they are usually treated as self-contained units for the purposes of identification and change control.        All configuration items (CIs) are uniquely identified by names, version numbers, and other attributes. CIs vary in complexity, size and type. They can range from an entire service which may consist of hardware, software and documentation, to a single program module or a minor hardware component.”        
It is useful to be able to transform inventory attribute data discovered by other automated inventory discovery systems such as the one provided by the assignee of the present invention, BDNA, into the IBM Tivoli CMDB data model, for the reasons given above. In such cases, it makes sense to provide a layer of isolation and mapping between the BDNA internal data structures and the outside system and only expose through the layer the necessary models and data of the BDNA system. This intermediary layer allows the BDNA system and data structures to continue to evolve without impacting the use of BDNA data in external systems.
The framework and functionality of the intermediate layer:
1) provides a layer of isolation between the BDNA internal data model and what is exposed to outside sources;
2) map out and helps solve differences between the BDNA data model for the discovery data and the data model representation of an outside source or target system;
3) provide runtime support for processing BDNA's discovery data into normalized data required by the external system in the form of a java code snippet.
4) provide a consistent, scalable and manageable way of processing the BDNA model and extracting it to an outside target.